Skip to content

fix(rust-ci): make the newly-wired GitLab cargo jobs actually pass - #74

Merged
hyperpolymath merged 4 commits into
mainfrom
claude/odds-sods-pm-goals-xktszo
Jul 21, 2026
Merged

fix(rust-ci): make the newly-wired GitLab cargo jobs actually pass#74
hyperpolymath merged 4 commits into
mainfrom
claude/odds-sods-pm-goals-xktszo

Conversation

@hyperpolymath

Copy link
Copy Markdown
Owner

Follow-up to #71, closing the gap I flagged there: the GitLab cargo-* jobs were "reviewed by inspection, not runnable in the sandbox." I have a working Rust toolchain here, so I actually ran all nine first-party crates through cargo build/test/fmt. Result: 8 of 9 build clean once fixed, 1 is a known-optional non-builder. Three commits:

1. fix(selur): add missing tokio AsyncReadExt import (02ff456)

services/selur has never compiled. sign_image had a function-local use tokio::io::AsyncReadExt;, but generate_keypair (a second call site) also does file.take(..).read_to_string(..) without the trait in scope — so .take() resolved to Iterator::take on tokio::fs::File and failed (E0599/E0282). The dormant GitLab jobs never caught it, and nif-build.yml doesn't cover services/. Hoisted the import to module scope, dropped the redundant local one, removed mut from two read-only bindings. cargo build --release + cargo test pass.

2. style(rust): cargo fmt all first-party crates (1d743b2)

The rustfmt job (not allow_failure) runs cargo fmt -- --check per crate; all 8 failed because the code was never fmt-checked while the job was dormant — same story as the mix format sweep in #71, for Rust. Pure cargo fmt output, no logic changes.

3. fix(gitlab-ci): quarantine the non-building quic_transport NIF (89a4c1b)

opsm_ex/native/quic_transport does not compile: pinned h3 0.0.6 / h3-quinn 0.0.7 predate quinn 0.11's now-private StreamId field, and with no committed Cargo.lock the fresh resolve breaks. It's an optional QUIC/HTTP3 NIF — Opsm.Transport.QuicNif swallows a failed :erlang.load_nif and falls back to HTTP/2 (nif_loaded? is hard-coded false), so the Elixir side (807 tests) runs fine without it, and no CI builds it today. Rather than sink a full pre-1.0 h3-ecosystem migration into optional aspirational code, I removed it from $RUST_CRATE_DIRS and the rules:/artifacts lists, with a QUARANTINED header note stating the un-quarantine condition (migrate the h3/h3-quinn/quinn triple to a compatible set + commit a lockfile). Flagged as a follow-up decision for you — see below.

Verified (real Rust 1.9x toolchain, this environment)

  • All 8 kept crates: cargo build --release ✓, cargo fmt -- --check ✓; checky-monkey tests 4/4, others build clean (0 tests defined)
  • .gitlab-ci.yml parses; only 2 quic_transport mentions remain (both the header note)
  • just toolchain-check

For your call (not done here)

  • quic_transport migration: the h3 crate is pre-1.0 and churns hard (recv_data now returns impl Buf, send-side API changes, etc.) — a real migration, not a version bump. Worth doing only if QUIC/HTTP3 transport is on the near-term roadmap; otherwise the quarantine + HTTP/2 fallback is the honest steady state.
  • The cargo-audit/cargo-deny job bodies still aren't exercised here (installing those tools from crates.io for 8 crates wasn't worth the sandbox time); the build/test/fmt jobs are now genuinely verified.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Kq24sZCEohSrNFXSuEuz6C


Generated by Claude Code

claude added 3 commits July 21, 2026 20:15
selur has never compiled: sign_image had a function-local
`use tokio::io::AsyncReadExt;` but generate_keypair (a second call site
added later) also calls `.take(..).read_to_string(..)` without the trait
in scope, so `file.take(1024*1024)` resolved to Iterator::take on
tokio::fs::File and failed with E0599/E0282. The GitLab cargo-* jobs
never caught it because they were dormant until they were wired to run
(#71); the NIF/service build in nif-build.yml doesn't cover services/.

Hoist the import to module scope (covering both call sites, dropping the
now-redundant local one) and drop the unnecessary `mut` on the two
read-only File bindings. Verified: `cargo build --release` and
`cargo test` both pass.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Kq24sZCEohSrNFXSuEuz6C
The GitLab `rustfmt` job (not allow_failure) loops over every first-party
crate running `cargo fmt -- --check`; all eight failed because the code
had never been fmt-checked while the job was dormant. Pure `cargo fmt`
output across the eight buildable crates (opsm-ui/tui, opsm_pq_nif, and
the six services/*), no logic changes. quic_transport is left untouched
(quarantined; does not build). Verified: every crate is now fmt-clean
and still builds.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Kq24sZCEohSrNFXSuEuz6C
…argo jobs

Wiring the cargo-* jobs to actually run (#71) exposed that
opsm_ex/native/quic_transport does not compile: its pinned h3 0.0.6 /
h3-quinn 0.0.7 predate quinn 0.11's private StreamId field, and with no
committed Cargo.lock the fresh dependency resolve breaks. It is an
OPTIONAL QUIC/HTTP3 NIF — Opsm.Transport.QuicNif swallows a failed
:erlang.load_nif and falls back to HTTP/2 (nif_loaded? is hard-coded
false), so the Elixir side runs without it and no CI builds it today.

Remove it from $RUST_CRATE_DIRS (the build loop) and from every
`rules: exists:` / artifacts list, with a QUARANTINED header note giving
the un-quarantine condition: migrate the h3/h3-quinn/quinn triple to a
mutually-compatible set and commit a lockfile. Tracked as a follow-up.
The remaining eight crates all build, test, and fmt-clean locally.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Kq24sZCEohSrNFXSuEuz6C
@hyperpolymath
hyperpolymath marked this pull request as ready for review July 21, 2026 21:26
@hyperpolymath
hyperpolymath merged commit 3409fa1 into main Jul 21, 2026
23 of 24 checks passed
@hyperpolymath
hyperpolymath deleted the claude/odds-sods-pm-goals-xktszo branch July 21, 2026 21:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants